Day 5 結尾講到，Instructions 8000 字元爆炸之後，我被迫把細節搬到 Knowledge。當時心想「沒問題，反正塞一份大檔就好」。
結果第一份「全部塞在一起」的 Knowledge 檔，大概有 3 萬多字，然後就GG了
於是開始拆，一次一次的測試過後，到現在穩定在 14 份。
每次的拆檔都不是「為了拆而拆」，是踩到具體問題或者需求，經過評估過後才進行
這篇就是 14 份的分工地圖
先回答最常被問的問題：「不就放一份大檔讓 GPT 自己讀就好？」
一份大檔的缺點：
拆成多份的好處：
流程與規則、看計分去 SA就緒度評分，直覺代價是檔案之間會有連動，這是後續的主題。先記著有這條，但好處遠大於這個代價。
把 14 份依職責分類，會長這樣：
| 檔名 | 職責 | 觸發時機 |
|---|---|---|
| 開場白 | 新對話開場的逐字稿、4 個 Conversation Starter 對應的回應、開場後的路由規則 | 每次新對話 |
開場白被獨立拉出來，是因為它要逐字輸出（不是改寫），這是 Day 5 講的 Conversation Starters 設計，每一字都重要，所以必須鎖在一份單獨的檔，避免 GPT 即興發揮。
| 檔名 | 職責 | 觸發時機 |
|---|---|---|
| 問題題庫 | 8 個區塊的所有問題、選項、總結模板 | 主要問答流程 |
| SA就緒度評分 | 100 分制計分規則、10 級成長標籤、進度表格格式 | 每次回覆時計分 |
| 流程與規則 | 4 種模式判定、檔案上傳分類、最終產出流程 | Instructions 引用 |
| 規格基線檢查表 | 5 題系統決策必問、10 類功能規格邊界 | 區塊 4 結尾追問 |
這 4 份是鼠勾以的「大腦」。改任何一份都會影響整體行為，所以後續的設計關聯檢查文件特別關注它們。
| 檔名 | 職責 | 觸發時機 |
|---|---|---|
| 例外情境檢查表 | 10 類功能類型的例外情境 + Given-When-Then 模板 | 區塊 7 |
| 格式範例與指引 | Mermaid 流程圖規範、欄位確認表、優先級格式 | 區塊 5、6 |
| 參與者協作圖 | Swimlane 觸發條件、5 類 Actor 提示、Mermaid 規範 | 區塊 5 端對端流程確認後 |
| 挑戰檢查規則 | 6 類挑戰觸發條件、跨區塊矛盾偵測、風險備註標記 | 每次使用者回答後 |
| 產出前自檢 | 6 大類交叉比對檢查（流程圖/欄位/例外/待確認/跨區塊/系統決策） | 最終產出步驟 13 |
| 工時估算參考 | 複雜度分類、角色拆分、Buffer 規則、信心度公式 | 最終產出階段 |
| 鼓勵文字庫 | 依分數區間與互動情境提供鼓勵語句與顏文字規則 | 區塊完成、得分、卡住等正向時機 |
這 7 份是「在特定時機才被讀」的工具書，平常不會干擾主流程。它們之所以被拆出來，是因為改動頻率跟核心引擎不一樣，鼓勵文字庫可以一週改三次也沒事，但 SA就緒度評分改一個數字會牽動整套機制。
| 檔名 | 職責 | 觸發時機 |
|---|---|---|
| PRD模板 | PRD 結構、各章節、Persona、Feature 詳細規格、AC 格式 | 最終產出組裝時 |
| 待確認清單模板 | 6 類分類（業務/技術/邏輯/欄位/邊界/UI）、4 種標記（必確認/可預設/已確認/風險備註） | 最終產出組裝時 |
這 2 份決定「最後吐出來的 PRD 長什麼樣」。它們跟其他檔的耦合最低，因為它們是純粹的輸出格式描述。
補一件常被問的事：「你怎麼確定鼠勾以問的這些題目夠了、不會漏？」
這個框架是從我自己寫過、跑過、被工程師認可的一份 PRD 反推出來的。
我的本職是 PM，現在跟著開發團隊一起研究AI in SDLC的導入，也使用我寫出的文件，成功地讓案子上線。
這份比較完整的 PRD，前後端都用它做完了實作、產出沒卡關、上線後也穩，對我來說就是一份「框架已經被驗證過」的樣本。它有目錄、有 Persona、有 User Story、有 AC、有畫面清單、有例外情境，每一塊都被前後端在實作時實際用到。
於是我做的事情很單純：
這 14 份 Knowledge 的內容就是這樣來的，直接對應一份能跑、能交付、能上線的 PRD，倒推回去回答「要把這份文件寫出來，事前該問什麼」。
但這也帶出鼠勾以存在的另一個理由。
我會反覆讀同一份 PRD，邊讀邊補：把缺的補上、把含糊的釐清、把例外情境想完才送出。職業直覺會逼我這樣做。
每個公司的分工不同，我們的需求方PM 通常還需要包涵 行銷、營運、業務、客服管理等，他有的時間會相對的更少，或許不是他不做，是時間不足，也沒有這樣的經驗。
所以這套工具的角色，是替他做「可能會，但需要引導」的事，在他送出之前，逼他被問一輪、被挑戰一輪、被打分一輪。每一題、每一個挑戰、每一個自檢，本質上都在模擬「在交付前的最後一次自我提問」。
如果你要做類似的事情，怎麼決定一個規則「該放在哪一份」、什麼時候該拆出新檔？我的判準有四條：
四條都符合，毫不猶豫拆。只符合一兩條，先觀察。不要為了「看起來整齊」而拆，拆了就要付出檔案間連動的維護成本。
鼠勾以的 14 份 Knowledge 是踩坑踩出來的數字，不是一開始就規劃好的，是根據一直測試，體感調整，最後定型出來的。
每一次拆或合，背後都有具體問題。如果你也在做類似的工具，別怕一開始很亂，拆檔的時機都是被問題逼出來的，提早規劃反而會過度設計。
明天 我會把另一條軸拉出來：Instructions 8000 字元怎麼省。
一開始爆過，現在剛好夠用。哪些一定要留在 Instructions、哪些可以移到 Knowledge。
這是 iThome 鐵人賽系列文章。明天見。
iThome鐵人賽
看影片追技術